Skip to content

Conversation

@penelopeysm
Copy link
Member

@penelopeysm penelopeysm commented Oct 24, 2025

In general there are two things that samplers return per iteration: parameter values, and sampler statistics.

getparams was added previously to cover the first one, but there's no interface function for the second.

Currently, for Turing's external sampler interface, external samplers are expected to implement Turing.Inference.getparams and Turing.Inference.getstats

This is a mistake, because external samplers shouldn't need to depend on Turing, they should only depend on AbstractMCMC and LogDensityProblems (because they only need to take an AbstractMCMC.LogDensityModel and call LogDensityProblems.logdensity on its wrapped model). I'm now trying to unravel this, hence the need for this function.

In the same vein, this PR also moves requires_unconstrained_space from Turing to here. I'm less certain about this. Please see Slack for discussion. But I think that whether a sampler requires unconstrained space or not is a property of the sampler (and thus belongs in the package that defines AbstractSampler), not a property of how it interacts with Turing.

@github-actions
Copy link
Contributor

AbstractMCMC.jl documentation for PR #182 is available at:
https://TuringLang.github.io/AbstractMCMC.jl/previews/PR182/

Copy link
Member

@mhauru mhauru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not obvious to me what unconstrained should default to. I guess most samplers need it, so true makes sense from that point of view. I could also see an argument that false is the simpler choice, in that you get the values exactly as the model sees them. Although from a LDP point of view that doesn't really matter, it just takes floats and gives log densities. So happy with this, but paused to wonder about the default.

@penelopeysm
Copy link
Member Author

I would also be quite happy to leave out the default and force the user to specify it (this is already quite breaking for external samplers so another breaking change won't matter too much).

@penelopeysm
Copy link
Member Author

I think, let's go with this for now, since the main drawback of linking (i.e. requires_unconstrained_space = true when it doesn't need to be) is just reduced performance, whereas the main drawback of not linking is that it will error or possibly yield incorrect results.

@penelopeysm penelopeysm merged commit e58f735 into main Oct 27, 2025
17 of 18 checks passed
@penelopeysm penelopeysm deleted the py/getstats branch October 27, 2025 14:50
@codecov
Copy link

codecov bot commented Oct 27, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.00%. Comparing base (e4305cb) to head (960b099).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@     Coverage Diff     @@
##   main   #182   +/-   ##
===========================
===========================

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Retrieve sampler statistics from the sampler's `state` as a `NamedTuple`.
"""
function getstats end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd hope we have more specific guidelines on how samplers should implement or use this API.

penelopeysm added a commit to TuringLang/Turing.jl that referenced this pull request Nov 5, 2025
Following on from:

- TuringLang/AbstractMCMC.jl#182 Adding the
interface function `AbstractMCMC.getstats`
- TuringLang/AdvancedHMC.jl#471 and
TuringLang/AdvancedMH.jl#119 Implementing them
for AdvancedHMC and AdvancedMH

this PR changes Turing's external sampler interface to exclusively use
AbstractMCMC functions. **With this PR, anyone who defines an external
sampler will only need to depend on AbstractMCMC (which they presumably
already do, because it is a sampler) and LogDensityProblems (which is
already a dep of AbstractMCMC).** No need for a Turing extension.

To be precise, it makes the following changes:

- Previously where one had to define `Turing.Inference.getparams`, now
one has to define `AbstractMCMC.getparams`.
- Previously there was no way to include sampler stats in the resulting
chain, now one can define `AbstractMCMC.getstats`.
- The default for `Turing.Inference.isgibbscomponent` is changed to
`true`, so that external sampler packages don't need to override it
(unless absolutely necessary).

As an example implementation, this PR contains a test mock (note how it
doesn't require a Turing dep):


https://github.com/TuringLang/Turing.jl/blob/06752c41a97cd0dc37bb8700ab7a2d06f50f4f76/test/mcmc/external_sampler.jl#L20-L74
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants